Catching up to the live playhead in live streaming

ABSTRACT

Techniques are described for reducing the delay between the live playhead of live streaming content and the client playhead of a client device consuming the live stream. In one technique, an increased playback speed is used by the media player on the client device so that the delay is gradually reduced. In another technique, the media player jumps forward in the stream, skipping content identified as expendable.

INCORPORATION BY REFERENCE

An Application Data Sheet is filed concurrently with this specificationas part of this application. Each application to which this applicationclaims benefit or priority as identified in the concurrently filedApplication Data Sheet is incorporated by reference herein in itsentirety and for all purposes.

BACKGROUND

Live streaming content includes channels or feeds with scheduled content(e.g., premium movie channels) and live broadcasts (e.g., sportingevents, news, etc.). Unlike video-on-demand (VOD) content, livestreaming content often does not have a distinct end point and maycontinue indefinitely. In addition, VOD content may be buffered inclient devices well in advance of the client playhead (i.e., the contentfragment currently being rendered by the client). This is typically notthe case for live content because of the constraint that the delaybetween the live playhead (i.e., the latest content fragment available)and the client playhead be as low as possible.

Because content services that provide live content often prioritizeminimizing the delay between the live and client playheads, this has thepotential to result in buffering events in which client devices run outof content fragments to play back. This is particularly the case forclients that maintain short buffers. Each buffering event for a givenclient device introduces additional delay between the live and clientplayheads (beyond the inherent latency associated with making thecontent available via a streaming protocol). For live content having arelatively long duration, e.g., a live sporting event, some clientdevices may fall several minutes behind the live playhead. Not onlymight this negatively affect viewer experience, it might also result inlack of compliance with the provisions of service level agreements.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an illustration of a delay between the live and clientplayheads of a live content stream.

FIG. 2 is a simplified diagram of a computing environment in whichimplementations enabled by the present disclosure may be practiced.

FIG. 3 is a simplified diagram of an example of a client device that maybe used with implementations enabled by the present disclosure.

FIG. 4 is a flowchart illustrating operation of a particularimplementation.

FIG. 5 is a flowchart illustrating operation of a particularimplementation.

DETAILED DESCRIPTION

This disclosure describes techniques for reducing the delay between thelive playhead of live streaming content and the client playhead of aclient device consuming the live stream. In some cases, an increasedplayback speed is used by the media player on the client device so thatthe delay is gradually reduced. The increase in the playback speed ispreferably small enough so that the faster playback is not perceptibleto a human viewer. In other cases, the media player jumps forward in thestream, skipping content that is considered expendable, e.g., blackframes, slate frames (e.g., an image with “please stand by” or “we'll beright back), low-value advertising content, etc. Using these mechanismsseparately or in combination, the client playhead may be brought closerin time to the live playhead. An example will be instructive.

Suppose two friends who are avid soccer fans are both watching livestreams of the World Cup final match on their tablets while messagingeach other. One of the friends on device 102 is using cellular data in acrowded public location to connect with the stream while the other ondevice 104 is using wifi on his home network. Because device 102 iscompeting for bandwidth with everyone else at its location itexperiences multiple buffering events, and the client playhead fallsbehind that of his friend's device 104 which is consuming the streamwith considerably more available bandwidth and is therefore much closerin time to the live playhead. When the viewer associated with device 104triumphantly texts his friend as the ball hits the back of the net, theviewer associated with device 102 is understandably confused andfrustrated. Using techniques enabled by the present disclosure, thedelay resulting in this frustration can be significantly reduced orsubstantially eliminated.

Live streaming content is sometimes annotated with metadata in real timeby human operators as the content is being generated. As part of thisannotation, segments of the content may be identified by annotators asbeing expendable. For example, when the cameras at the event focus onthe crowd or an aerial view of the surrounding geography rather than thepitch for a few seconds, or when play is stopped for an injury, suchsegments of the content can be identified by a human annotator asexpendable. When the media player on client device 102 reaches such apoint in the live stream, it can skip ahead to the next fragments in thestream that are not identified as expendable. In this way, the delaybetween the live playhead and the client playhead of device 102 can beshortened, reducing the likelihood of viewer frustration.

Alternatively or in conjunction with the skipping of content, theplayback speed on device 102 can be increased for a period of time in away that is not noticeable to the viewer to allow for a more gradualreduction in the delay between the live and client playheads. And ifboth client devices 102 and 104 are attempting to minimize this delay insimilar fashion, it is much more likely that the respective viewers willbe having viewer experiences that are more closely synchronized in time.

FIG. 2 illustrates an example of a computing environment in which avideo content service 202 provides live streaming content (e.g., audioor video) via network 204 to a variety of client devices (206-1 through206-5) in accordance with the techniques described herein. Contentservice 202 may conform to any of a wide variety of architectures suchas, for example, a services platform deployed at one or moreco-locations, each implemented with one or more servers 203. Network 204represents any subset or combination of a wide variety of networkenvironments including, for example, TCP/IP-based networks,telecommunications networks, wireless networks, satellite networks,cable networks, public networks, private networks, wide area networks,local area networks, the Internet, the World Wide Web, intranets,extranets, etc. Client devices 206 may be any suitable device capable ofconnecting to network 204 and consuming live streaming content providedby service 202. Such devices may include, for example, mobile devices(e.g., cell phones, smart phones, and tablets), personal computers(e.g., laptops and desktops), set top boxes (e.g., for cable andsatellite systems), smart televisions, gaming consoles, wearablecomputing devices (e.g., smart watches or smart glasses), etc.

At least some of the examples described herein contemplateimplementations based on computing models that enable ubiquitous,convenient, on-demand network access to a shared pool of computingresources (e.g., networks, servers, storage, applications, andservices). As will be understood, such computing resources may beintegrated with and/or under the control of the same entity controllingcontent service 202. Alternatively, such resources may be independent ofcontent service 202, e.g., on a platform under control of a separateprovider of computing resources with which content service 202 connectsto consume computing resources as needed.

It should also be noted that, despite any references to particularcomputing paradigms and software tools herein, the computer programinstructions on which various implementations are based may correspondto any of a wide variety of programming languages, software tools anddata formats, may be stored in any type of non-transitorycomputer-readable storage media or memory device(s), and may be executedaccording to a variety of computing models including, for example, aclient/server model, a peer-to-peer model, on a stand-alone computingdevice, or according to a distributed computing model in which variousfunctionalities may be effected or employed at different locations.

In the following examples and for the sake of simplicity, contentservice 202 is described as if it were integrated with the platform(s)that provides the live streaming content to client devices. However, itwill be understood that content service 202 may provide access to livestreaming content in conjunction with one or more content deliverynetworks (e.g., CDN 214) that may or may not be independent of contentservice 202. In addition, the source of the live content may or may notbe independent of content service 202 (e.g., as represented by contentprovider server 216). The range of variations known to those of skill inthe art are contemplated to be within the scope of this disclosure.

Some of the implementations enabled by the present disclosurecontemplate logic resident on the client devices consuming livestreaming content from content service 202;

such logic being configured to make decisions in conjunction withconsuming the video content such as, for example, monitoring the delaybetween playheads, increasing playback speed, and/or skipping expendablecontent. The logic might be part of an existing algorithm or module onthe client device or implemented to work in conjunction with such analgorithm or module. The logic might be implemented, for example, in amedia player on the client device or as a separate application or moduleresident on the client device.

It should also be noted that implementations are contemplated in which,in addition to content delivery logic 210 (which facilitates variousaspects of content delivery to client devices 206), content service 202may include logic that facilitates at least some aspects of monitoringand reducing the delay between playheads as described herein (e.g., asrepresented by playhead catchup logic 211). For example, such logicmight be used to associate metadata with fragments or segments of thecontent that identify expendable content that can potentially be skippedto allow for reduction of the delay between the live playhead and clientplayheads. As discussed below, this may be done manually (e.g., by humanoperators), using existing content metadata, or by real-time analysis ofthe frames or fragments of the content. Such logic might also beconfigured to determine whether and how far a particular client isbehind the live playhead and/or take steps or send instructions to theclient (e.g., to initiate higher-speed playback or skipping of content)to support getting the client's playhead closer to the live playhead.

In addition to providing access to the live streaming content, contentservice 202 may also include a variety of information related to thelive streaming content (e.g., other associated metadata and manifests indata store 212 to which service 202 provides access. Alternatively, suchinformation about the live streaming content, as well as the livestreaming content itself may be provided and/or hosted by one or moreseparate platforms, e.g., CDN 214. It should be noted that, while logic210 and 211, and data store 212 are shown as integrated with contentservice 202, implementations are contemplated in which some or all ofthese operate remotely from the associated content service, and/or areunder the control of an independent entity. From these examples, thoseof skill in the art will understand the diversity of use cases to whichthe techniques described herein are applicable.

A block diagram of an example of a client device 300 suitable for usewith various implementations is shown in FIG. 3. Device 300 includes oneor more single or multi-core processors 302 configured to execute storedinstructions (e.g., in device memory 320). Device 300 may also includeone or more input/output (I/O) interface(s) 304 to allow the device tocommunicate with other devices. I/O interfaces 304 may include, forexample, an inter-integrated circuit (I2C) interface, a serialperipheral interface (SPI) bus, a universal serial bus (USB), an RS-232interface, a media device interface, and so forth. I/O interface(s) 304is coupled to one or more I/O devices 306.

Device 300 may also include one or more communication interfaces 308configured to provide communications between the device and otherdevices. Such communication interface(s) 308 may be used to connect tocellular networks, personal area networks (PANs), local area networks(LANs), wide area networks (WANs), and so forth. For example,communications interfaces 308 may include radio frequency modules for a3G or 4G cellular network, a WiFi LAN and a Bluetooth PAN. Device 300also includes one or more buses or other internal communicationshardware or software (not shown) that allow for the transfer of data andinstructions between the various modules and components of the device.

Device 300 also includes one or more memories (e.g., memory 310). Memory310 includes non-transitory computer-readable storage media that may beany of a wide variety of types of volatile and non-volatile storagemedia including, for example, electronic storage media, magnetic storagemedia, optical storage media, quantum storage media, mechanical storagemedia, and so forth. Memory 310 provides storage for computer readableinstructions, data structures, program modules and other data for theoperation of device 300. As used herein, the term “module” when used inconnection with software or firmware functionality may refer to code orcomputer program instructions that are integrated to varying degreeswith the code or computer program instructions of other such “modules.”The distinct nature of the different modules described and depictedherein is used for explanatory purposes and should not be used to limitthe scope of this disclosure.

Memory 310 includes at least one operating system (OS) module 312configured to manage hardware resources such as I/O interfaces 304 andprovide various services to applications or modules executing onprocessor(s) 302. Memory 310 also includes a user interface module 316,a content rendering module 318, and other modules. Memory 310 alsoincludes device memory 320 to store a wide variety of instructions andinformation using any of a variety of formats including, for example,flat files, databases, linked lists, trees, or other data structures.Such information includes content for rendering and display on display306(1) including, for example, any type of video content. In someimplementations, a portion of device memory 320 may be distributedacross one or more other devices including servers, network attachedstorage devices, and so forth.

The logic or computer program instructions used to support reducing thedelay between live and client playheads as described herein (representedby playback speed module 319 and content skipping module 321) may beimplemented in a variety of ways. For example, at least some of thisfunctionality may be implemented as part of the code of a media playeroperating on device 300. Alternatively, modules 319 and 321 may beimplemented separately from and interact with the device's media player,web browser, mobile app, decoder, etc.

And as mentioned above, implementations are contemplated in which atleast a portion of the logic or computer program instructions may resideon a separate platform, e.g., service 202, CDN 214, etc.; potentiallyworking in conjunction with the client-side logic to reduce the delaybetween the respective playheads. Suitable variations and alternativeswill be apparent to those of skill in the art. It will also beunderstood that device 300 of FIG. 3 is merely an example of a devicewith which various implementations enabled by the present disclosure maybe practiced, and that a wide variety of other devices types may also beused (e.g., devices 206-1 to 206-5). The scope of this disclosure shouldtherefore not be limited by reference to device-specific details.

The delivery of live streaming content to a client device according to aparticular implementation is illustrated in the flow chart of FIG. 4.This and other examples described herein assume the use of H.265encoding (also commonly referred to as HEVC) for video content. However,it will be understood that the basic principles described herein may beemployed with any of a variety of video and audio codecs including, forexample, MPEG-1, MPEG-2, MPEG-4 Part 2, VC-1, H.263, VP8,VP9, Daala, andH.264. The example illustrated in FIG. 4 also assumes a media player onthe client device that includes logic (e.g., modules 319 and 321)configured to manage at least some aspects of reducing the delay betweenthe live and client playheads as described herein. Again, these detailsare merely presented by way of example.

When a user wants to connect with a content service using a clientdevice, the connection is typically achieved through some kind of loginprocess to the service in a user interface presented on the clientdevice. Content playback is provided, for example, via a resident mediaplayer, web browser, or mobile app. Access to content over the Internetis typically governed by a DRM system such as Google's Widevine,Microsoft's PlayReady, Apple's FairPlay, or Sony's OpenMG to name a fewrepresentative examples. Live streaming content is typically deliveredin an encrypted stream using any of a variety of encryption technologiesincluding, for example, various Advanced Encryption Standard (AES) andElliptic Curve Cryptography (ECC) encryption techniques. The live streammay also be delivered using an adaptive bit rate streaming techniquesuch as, for example, MPEG-DASH (Dynamic Adaptive Streaming over HTTP),Apple's HLS (HTTP Live Streaming), or Microsoft's Smooth Streaming, toname a few representative examples. It should be noted that thetechniques described herein are compatible with a wide range of contentservices, media players, DRM systems, encryption technologies, andstreaming technologies, the details of which are known to those of skillin the art. The nature and operation of these technologies willtherefore not be described in detail to promote clarity.

Referring now to FIG. 4, when live content is selected in a userinterface on a client device (402), a request for the content is sent tothe corresponding content service (404). The content service providesthe client device with the information the client device needs toacquire a stream of the content (406). This may include, for example,DRM licenses, a decryption key, content metadata, and information aboutwhere the client can request the fragments of the selected content atvarious resolutions (e.g., a manifest). The client device then acquiresa stream of the live content using the information received from thecontent service (408).

As the client device is consuming the live content, the delay betweenthe live playhead and the client playhead is tracked (410). This may bedone in a variety of ways. For example, logic on the client device cancount the cumulative amount of time required to recover from rebufferingevents. In a simpler approach, a fixed amount of time could be added tothe delay for each rebuffering event. In another example, time stampsassociated with the recently requested fragments and representative ofor close in time to the live playhead could be compared to a local clockon the client device.

In another example, the time reference used by logic on the clientdevice to determine the delay could be a time stamp associated with oneor more fragments acquired at the beginning of the session. For example,logic on the client could compare the difference between such a timestamp and that of a later fragment with actual time elapsed on theclient device (e.g., as determined by a local clock) to determine theextent to which the delay has grown over time. In another example,server-side logic could determine the delay for a particular client bycomparing the time stamp for a recently requested fragment by thatclient with the time stamp for the fragment most recently made availableby the content service, or the latest fragment requested by any clientconsuming the live stream. Where server-side logic determines the delayfor a particular client device, the server-side logic could alsodetermine whether the delay exceeds a threshold and, when that occurs,transmit a message or an instruction to the client to initiate use ofone or both of the catch-up mechanisms. Alternatively, the server-sidelogic could periodically transmit the delay to the client device fordecision making on the client.

It should be noted that the delay value being tracked may only be anapproximation of the actual delay between the live and client playheads.That is, both client and server-side logic might use time referencesthat are suitable proxies for one or both of the playheads withoutdeparting from the scope of this disclosure. For example, the time stampassociated with a fragment most recently requested by a client devicewill likely differ from the time the fragment is actually rendered anddisplayed by the client device, but may otherwise be suitable forpurposes of determining a reliable approximation of the actual delay. Inanother example, the time stamp associated with the fragment mostrecently made available by the content service might be earlier than thetime at which the fragment becomes available to some client devices.More generally, and as will be appreciated by the diversity of theforegoing examples, there are many ways in which a delay between thelive playhead and the client playhead for a particular client may betracked, determined, or approximated for use as described herein. Thescope of the present disclosure should therefore not be limited byreference to such examples.

Referring again to FIG. 4, if the delay between the live playhead andthe client playhead exceeds a predetermined threshold (412), theoperation of logic configured to reduce the delay is initiated (414).The threshold may be selected to keep the client device acceptably closeto the live playhead while ensuring a particular level of contentquality. The threshold might also be selected, at least in part, toensure compliance with any applicable service level agreement(s). And asmentioned above, the logic initiated may be configured to increase theplayback speed of the client device's media player, skip playback ofexpendable content, or use a combination of these “catch-up mechanisms.”Once the delay is reduced to an acceptable level (416) (which may or maynot be the same as the threshold used to trigger use of the catch upmechanism(s)), use of the catch-up mechanism(s) is/are terminated (418),and tracking of the delay continues (410).

An example of the operation of an implementation that uses both of thesemechanisms is illustrated in the flowchart of FIG. 5. According to theimplementation depicted, when the delay between playheads exceeds thethreshold (e.g., as determined in 412), the playback speed of the mediaplayer on the client device is increased (502). The amount by which theplayback speed is increased may be relatively small, e.g., 2-5%, andpotentially as much about 15%. For example, for a normal playback framerate of 30 frames per second, the playback speed could be increased to32 or 33 frames per second. Ideally, the increase in playback speed isimperceptible to most human viewers and may be empirically determined,e.g., using viewer assessment by human subjects.

It should be noted that the increase in playback speed may be at leastpartially dependent on the type of content. For example, humans may morereadily distinguish an increase in playback speed for musical contentthan for content that is primarily visual in nature. So, for contentthat includes musical content (e.g., pure audio content, or video withsignificant musical content), the increase in playback speed may belower than for some video content. And although it is preferable thatthe increase in playback speed be imperceptible to some, most, or allhuman viewers, implementations are contemplated in which this does notneed to be the case.

According to some implementations, the increased playback speed may be aconstant speed. Alternatively, implementations are contemplated in whichthe playback speed may vary dynamically. For example, if the increasedplayback speed is not successful in reducing the delay between the liveand the client playheads after some programmable period of time, theplayback speed might be further increased. In another alternative, theplayback speed for different types of content may be different. Forexample, segments of the content that include musical content could beidentified or detected (e.g., from content metadata) and the playbackspeed could be reduced for those segments while playback of segments notincluding musical content could be at a higher rate. In anotheralternative, different playback speeds might be used for differentranges of delay so as to enable faster catch-up for larger delays.

Increased playback speed or content skipping might also affect orinteract with the operation of other logic on the client device such as,for example, adaptive bit rate selection logic. For example, such logicmight be configured to request fragments at reduced quality when themedia player is operating at a higher playback speed so that thehigh-speed playback can continue even if available bandwidth is low.Alternatively, increased playback speed and/or content skipping might bedisabled where the content quality attainable by the adaptive bit rateselection logic is or would be negatively affected by the operation ofthe catch-up mechanisms (e.g., the video quality drops below athreshold). In some cases, the available bandwidth may be checked beforeinitiating use of a catch-up mechanism to ensure playback quality. Forexample, if available bandwidth is below a certain level, increasedplayback speed may be disallowed or, if already started, suspended.

Referring back to FIG. 5, and in parallel with the increased playbackspeed, the identification of expendable content in the live stream isinitiated (504). Each time one or more expendable content frames,fragments, or segments are encountered in the stream (506), playback ofthe expendable content is skipped (508). Such expendable content maycorrespond to any of a variety of breaks between the most relevant orinteresting segments of the content such as, for example, black frames,slate frames, credits, opening or closing montages, commercial breaks,etc.

As mentioned above, such segments of content may be identified withreference to metadata that is introduced into the live stream (e.g., asmetadata tags) by human operators in substantially real time. That is,human operators may view and annotate the live content (e.g., as it isreceived from the live content source) for a wide variety of purposessuch as, for example, dynamic insertion of advertisements, providingadditional descriptive content (e.g., sports play-by-play), rating ofcontent for different viewing audiences, etc. According to someimplementations, human operators annotate the live content byidentifying expendable content, i.e., content for which playback may beskipped on client devices that are sufficiently behind the liveplayhead. So, for example, as a human operator is viewing the stream ofa live sporting event close in time to the actual creation of thecontent, she can identify segments that correspond, for example, toviews of the crowd, commercial breaks, replay reviews, etc., byinserting metadata tags into the stream that are associated withindividual fragments, groups of fragments, or even longer segments.These tags may then be used (e.g., by content skipping module 321) toskip playback of the corresponding fragments.

In addition or as an alternative to being tagged by human operators,expendable content may be identified in a variety of other ways. Forexample and as mentioned above, expendable content might be identifiedusing information about the content that is provided by the contentprovider. For example, content providers often provide information(e.g., content stream metadata) about events or breaks in content (e.g.,commercial breaks, breaks between blocks of content, the beginning orend of scheduled content, the beginning of important live content, etc.)that may present opportunities for content skipping. Such events orbreaks might include a fade to black, a few black frames, or contentthat is less important to viewers (e.g., commercial breaks, credits,etc.). And using such information for catching up to the live playheadmay be advantageous in that there is a relatively high degree ofreliability in the timing of such events as they are explicitlyidentified by the content provider. Further, for some types of livestreams (e.g., streams of scheduled content), such events or breaks maybe relatively far out into the future and thus may be communicated tothe client well in advance.

In some implementations, the identification of expendable content may bebased on real-time or near-real-time video inspection and analysis. Forexample, video fragments, GOPs, and individual video frames can beanalyzed to determine whether they are black frames, or correspond toscenes in which the display images do not appreciably change for anextended period of time. As should be appreciated, such an approach maybe particularly important for live streams that do not follow a strictschedule, e.g., live sporting events in which commercial breaks or theend of the program is determined by play on the field.

Identification of expendable content may be done by the client (e.g.,content skipping module 321) with reference to either or both ofinformation from the content provider (e.g., in stream metadata), or byinspection of the fragments or frames of the current stream as they arereceived. For example, the client might be configured to identifylow-complexity or static content (e.g., by virtue of the relationshipsor dependencies among frames in a GOP). This might be done instead of orin addition to identification of expendable content on the server side(e.g., by playhead catchup logic 211).

Referring again to FIG. 5, the delay between the live and clientplayheads is monitored to determine whether operation of one or both ofthe catch-up mechanisms should be terminated. That is, for example, ifthe delay drops below a threshold (510), normal speed playback withoutcontent skipping may be resumed (512). The threshold used may be chosento get the client playhead as close as possible to the live playheadwithout negatively affecting the user experience in terms of contentquality and/or an unacceptably high rate of rebuffering events. Thethreshold might be the same as the one used to initiate operation of thecatch-up mechanisms (e.g., 412 of FIG. 4). Alternatively, some level ofhysteresis might be built into the system, using a lower threshold fortermination of higher-speed playback or content skipping to ensure thatthe client isn't rapidly switching between normal playback and use ofthe catch-up mechanisms. Either or both thresholds might be dynamic innature, depending, for example, on available bandwidth or a currentstate of an adaptive bit rate algorithm.

According to some implementations in which both catch-up mechanisms areemployed, different thresholds may apply to initiation and terminationof each mechanism. That is, increasing playback speed may allow for afiner control of the reduction of the delay between the live and clientplayheads as compared to the cruder but faster control represented bythe skipping of content. Implementations are therefore contemplated inwhich the threshold(s) associated with increased playback speed is lowerthan the threshold(s) associated with content skipping. For example, theincrease in playback speed might be initiated when the delay reaches 30seconds, but content skipping might not be initiated until the delayreaches a minute or more. This allows for a more brute force approach(represented by content skipping) for longer delays, while allowing fora more fine-grained and precise approach (represented by higher-speedplayback) for shorter delays.

And while the different catch-up mechanisms may be used in combination,they may or may not be used simultaneously. For example, the differentmechanisms might be used alternatively, e.g., with content skippingbeing used until the delay has decreased sufficiently to allow forfurther reduction using higher-speed playback. Variations on this themewithin the scope of the present disclosure will be understood by thoseof skill in the art.

While the subject matter of this application has been particularly shownand described with reference to specific implementations thereof, itwill be understood by those skilled in the art that changes in the formand details of the disclosed implementations may be made withoutdeparting from the spirit or scope of the invention. Examples of some ofthese implementations are illustrated in the accompanying drawings, andspecific details are set forth in order to provide a thoroughunderstanding thereof. It should be noted that implementations may bepracticed without some or all of these specific details. In addition,well known features may not have been described in detail to promoteclarity. Finally, although various advantages have been discussed hereinwith reference to various implementations, it will be understood thatthe scope of the invention should not be limited by reference to suchadvantages. Rather, the scope of the invention should be determined withreference to the appended claims.

What is claimed is:
 1. A client device, comprising: memory; an outputdevice; and one or more processors configured, in conjunction with thememory, to: acquire a stream of content for playback on the outputdevice, the content being characterized by an encoding according to anencoding scheme; determine that a delay between a live playhead of thecontent and a client playhead associated with the playback of thecontent exceeds a first threshold; in response to determining that thedelay exceeds the first threshold, increase a normal playback speed ofthe content by a media player on the client device to an increasedplayback speed without modifying the encoding of the content; anddynamically vary the increased playback speed resulting in a pluralityof different increased playback speeds, each of the different increasedplayback speeds being higher than the normal playback speed.
 2. Theclient device of claim 1, wherein the one or more processors areconfigured to achieve the increased playback speed by increasing anumber of frames per second of the content rendered and displayed on theoutput device without skipping frames of the content.
 3. The clientdevice of claim 1, wherein the increased playback speed is less thanapproximately 15% greater than the normal playback speed.
 4. The clientdevice of claim 1, wherein the one or more processors are furtherconfigured to: determine that the delay is below a second threshold, thesecond threshold being lower than the first threshold; and decrease theincreased playback speed.
 5. The client device of claim 1, wherein theone or more processors are further configured to: identify one or moreexpendable portions of the content using content metadata associatedwith at least some video fragments of the content; and skip playback ofat least one of the one or more expendable portions of the content. 6.The client device of claim 1, wherein the one or more processors arefurther configured to: determine that a playback quality of the contenthas dropped below a second threshold; and decrease the increasedplayback speed.
 7. The client device of claim 1, wherein the one or moreprocessors are further configured to determine the delay based on one ormore rebuffering events, or using time stamps associated with fragmentsor frames of the content.
 8. The client device of claim 1, wherein theone or more processors are configured to dynamically vary the increasedplayback speed by determining that the increased playback speed has notsufficiently reduced the delay and further increasing the increasedplayback speed.
 9. The client device of claim 1, wherein the one or moreprocessors are configured to dynamically vary the increased playbackspeed by reducing the increased playback speed for portions of thecontent that include a specific content type.
 10. The client device ofclaim 1, wherein the one or more processors are configured todynamically vary the increased playback speed by using the differentincreased playback speeds for different corresponding ranges of thedelay.
 11. A computer-implemented method, comprising: acquiring a streamof content for playback on an output device of a client device, thecontent being characterized by an encoding according to an encodingscheme; determining that a delay between a live playhead of the contentand a client playhead associated with the playback of the contentexceeds a first threshold; in response to determining that the delayexceeds the first threshold, increasing a normal playback speed of thecontent by a media player on the client device to an increased playbackspeed without modifying the encoding of the content; and dynamicallyvarying the increased playback speed resulting in a plurality ofdifferent increased playback speeds, each of the different increasedplayback speeds being higher than the normal playback speed.
 12. Themethod of claim 11, wherein increasing the normal playback speedincludes increasing a number of frames per second of the contentrendered and displayed on the output device without skipping frames ofthe content.
 13. The method of claim 11, wherein the increased playbackspeed is less than approximately 15% greater than the normal playbackspeed.
 14. The method of claim 11, further comprising: determining thatthe delay is below a second threshold, the second threshold being lowerthan the first threshold; and decreasing the increased playback speed.15. The method of claim 11, further comprising: identifying one or moreexpendable portions of the content using content metadata associatedwith at least some video fragments of the content; and skipping playbackof at least one of the one or more expendable portions of the content.16. The method of claim 11, further comprising: determining that aplayback quality of the content has dropped below a second threshold;and decreasing the increased playback speed.
 17. The method of claim 11,further comprising determining the delay based on one or morerebuffering events, or using time stamps associated with fragments orframes of the content.
 18. The method of claim 11, wherein dynamicallyvarying the increased playback speed includes determining that theincreased playback speed has not sufficiently reduced the delay andfurther increasing the increased playback speed.
 19. The method of claim11, wherein dynamically varying the increased playback speed includesreducing the increased playback speed for portions of the content thatinclude a specific content type.
 20. The method of claim 11, whereindynamically varying the increased playback speed includes using thedifferent increased playback speeds for different corresponding rangesof the delay.